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a: CUSP for Numerical Integration, 


FIGURE 1b: CUSP for Determining the Roots of Polynomials. 
The user types only the order of the equation and the 
polynomial coefficients. 
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8.30902 E+00 


IMAGINARY 
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0.58779=1-00 
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13 ACCEPT X 

X=3.P 

23 ! : Y=X-<SINFCX>-. 1*X) /CCOSFCX) 

3? IFCA3SFCX-Y)-. 003331)2, 2, 3 

STATEMENT NO. 3 LINE 33, UNDEFINED 


1) =2.3542375 


DTA7.: FOP DESK 

Setup 


53 GO TO 1 
STATEMENT NO. 2 
*P 

53 2 : 

2.3523419 
7? STOP 
3T0 D LINE 72 


4=1 .2345S7 
4 = 4 * 4 / 4 + 6 - 
1 = 1+1 =1 
GO TD 1 


7.3531743 
STOP LINE 73 
*S13 
X=9.2 

3. 4232333 
STOP LINE 7? 
*15 


ROOTS OF S I N ( X ) - . 1 *X BY NEWTONS METHOD 


00TS OF SI’-KX)-. 1*X BY NEWTONS METHOD 
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2o: FORDESK routine to estimate running time. 
1 was interrupted after one minute when the loop 
» found to be executed nearly 6,000 times. 


FIGURE 2b: Student problem solved m FORDESK. 
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texfon ffie ™ I I 0R (a routine for creating and modifying 
text on the tape from a remote console) and PIP (the Periph- 
eral Interchange Program, for the transfer of data from anv 

sequendng“ etc e ) V,Ce ‘° “ y ° Pti ° nS SUCh 38 lin ® 

CUSPS have also been developed at the University by both 
IS 0 ? '" 8 Centre staff and users. These routines have 
proved very popular during the time-shared periods, giving 
users fast access to computations such as the solution of linear 
equations, evaluation of the roots of polynomials, numerical 
integration, and desk calculator’ services. 

An important feature of these routines is that storage re- 
f ° r ' nd ' V , ldual Programs must be kept to a minimum 
so that the probability of obtaining service is high. This has 
meant a return to tight coding— an art that appeared to have 
been on the wane. With additional core and a swapping 
system, the demands due to storage limitation will not be so 
gretit It will, of course, still be important to keep program 
size down so as to reduce ‘swapping time’. 

A second feature which has been found to be important 
when designing a CUSP is that the computer would keep up 
a conversation with the user in many programs, so that not 
onlj will the uninitiated have no difficulty in using a program 
but the possibility of errors is reduced. Errors are also mini- 
mized if a wide latitude is given to the user in input format. 
Examples of typical CUSPS are shown in fig. 1. 

SOFTWARE REQUIREMENTS FOR TIME SHARING 
Time-sharing will minimize the waiting time between the 
programmers access to a computer. If the programmer is 
gainfully employed while waiting service, time-sharing will only 
result in dramatic increase in user efficiency (and hence 
machine efficiency) if software is available with which to 
match the environment. 

As powerful as debugging routines, such as DDT, are at the 
assembly language level, dichotomy between program prepara- 
tion, compiling and debugging does not assist the average user 
who codes and debugs at the source language level. 

FORDESK, a FORTRAN compatible language, is under 
continuing development at the University. It is a programming 
system which enables simultaneous editing, translation, execu- 
tion and debugging from a user’s console. Being FORTRAN 
compatible, not only is there no re-leaming problem (indeed it 
is a powerful teaching aid) but a working program may be 
dumped on tape and translated with a standard compiler— the 
loss of speed (10-100) in running a FORDESK program inter- 
pretively may be intolerable for a commonly used routine once 
it has been checked out. Not that this decision that the lan- 
guage be a FORTRAN subset was made without some reluct- 
ance. When originating a compiler there is an inclination to 
include features that would best suit the environment. For 
example, it is felt that a REPEAT statement would fit more 
naturally into on-line program composition than the equiva- 
lent DO statement. However, the decision made, it is the 
internal organisation and controls (such as the debugging aids) 
which are of interest. 

FORDESK — Appearance to the User 

FORDESK I, the version of FORDESK which was released 
towards the end of 1965, has ASSIGNMENT, GO TO, IF 
PAUSE, STOP, ACCEPT, and TYPE statements and with’ 
variable names limited to the characters A-Z may sound aus- 
tere, but it has proved to be extremely popular for small one- 
ott programs. This version was put together using routines for 
the translation of assignment statements developed for on-line 
C3kuIat 5 r ’ s f vRes and in the development of certain 
criDnccv*? 6011 ^ above. With these routines available, 
u ij u * concentrated on developing the commands that 
should be available for controlling and debugging programs 

tutT'scate FORDESK f ° re undertaking the Programming of a 

FORTRAN statements are entered directly from the user’s 
console, hne numbers being supplied by the computer. These 
fine numbers are in steps of ten making subsequent insertions 
possible without resequencing. Analysis takes place immediately 
and execution is normally carried out if no errors are detected 
The result of the execution appears on the user’s console giv- 
ing instant feed-back which may be of help in error detection 
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and allows FORDESK to be used as a desk calculator tiiSP 
the program is either running or the user tvping in ’ 

gram is said to be in ‘program mode’. The user mav at Pr ^‘ 
time exit to command mode in order to modify the Vim ^ 
or its flow. Commands available are: 

Z Uni* 10* 3 nCW Pr0gram and g0 int0 Program mode| 
insert (or overwrite) line n. 
start the program running at line n. 
insert a breakpoint at line n. 
proceed after an insertion has been made or a hr 
point has been encountered. 

proceed after a breakpoint going through this'll 
point n times. 
list line n. 

Lnl,n2 list lines nl through n2. 

R Resequence the line numbers (in steps of ten) 
<Vanable name/type out the value of this variable ■% 
The switches T (commence tracing) and N (cease tracihf 
may be inserted in parentheses after commands. The Dro 8 
will run without tracing unless commanded otherwise 
Any number of breakpoints may be inserted. The nroe™ 
is executed until the line at which a breakpoint has been-* 
placed is about to be executed. Command mode is immediate* 
entered and register examination may then take place, or am 
command executed. 

' u com ™and to be implemented which experience has sho 
to be useful is. An, m: attach statement number m to line 
Also desirable is selective tracing, where automatic print oi 
is limited to lines nominated by the programmer. An 

FORDESK featUreS wiI1 be necessary in the expand 

Some Problems of Partial Execution and Program Modific 
One of the major problems of partial execution followi 
progr am modification is that confusion occurs as to the ej 
f a ' us ,. of tbe resident program both with regard to legality 
and the values cuiTently associated with its variablesU For 
example, the deletion of a statement number could have;’ 
disastrous effect on previously working DO loops. Modifies 
tions to DIMENSION statements could similarly throw who' 
sections of program into error. 

The values held in dimensioned variables may be preset’ 
on an expansion of array size. If a similar algorithmic 
used when arrays were diminished the programmer mu/ 
alWtb f lar f es Jt indices which have been referenced 
allow the status of the program to remain, unless such infon 
ation is earned by the compiler. This comment also applie 
re F 10 '' al °f assignment statements when variablesgh 
suddenly be undefined on program re-execution. The stbrat 
requirements and additional loss of speed on execution nis 
make checking of such occurrences impracticable. It wo 
appear then, that partial execution, while bringing attent 
to immediate errors, will still require the programmer to hi 
considerable awareness of the process under his control 
execution after modification may well need to be more?* 
quent than hoped for from the view-point of consumption 
central processor time. 

In this context it would appear that a console offering? 
copy with program examination, modification and re-exa 
tion recorded in chronological order has advantages ov< 
character display. 

Some Storage Considerations - 

The pilot version of FORDESK I takes less than 3 
registers without undue effort made to conserve storage. ’ 
includes a wider than usual range of FORTRAN subroti 
held permanently in the usfer area. 

A sample of FORTRAN programs revealed that the aver 
length of a FORTRAN statement is of the order of 15 char 
ters. Fifty lines of FORDESK, with three words for sou; 
statements, and two words for line numbers, pointers ; 
various flags will then take up 250 words, allowing FOF — ’ 

I to fit in 2K. . 

The, expanded version (FORTRAN H, with 
FORMAT specifications) is expected to be under 4is.. ifei 
area required for variables, their book-keeping and DO Io 
information lists, will consist of under 150 words. Novi* 
users restrict arrays to ‘test size’ it appears that 5K wilf 
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for a reasonably powerful on-line interactive pro- 
than be restricted to two users it is proposed 
. 4K interpretive compiler among 6-8 users in a 
jtrant manner, and also allow greater effective 

, by 'allowing dynamic growth of impure areas. 

ifg¥ ' 

__ Staring 

for and implementation of re-entrant programs 

— sd systems are not new. Indeed modifications to 
>P-6 time-shared monitor to control such systems have 
' been proposed by DEC«s>. Here the compiler (or 

igram) is not held separately in core for each user 
-red between all users in core requesting the services 
routine. The program is split into two parts, a pure 
a user area containing information peculiar to the 
— called the impure part To make such a system 
„ ;Tf users are to be scheduled on a quantum of time 
f the pure part must be re-entrant. Here a re-entry is 
:• defined as a routine that allows unlimited multiple 
ices and exits before prior executions take place. When 
such routines it is necessary to adhere to certain addi- 
hoding^ conventions and it is essential that the routine 
.jlutely’ debugged before becoming operational, as hard- 
irotection cannot be operative. 

be scheduling of FORDESK users is not based on a 
—in of time basis but rather on a line basis (as from 
dure it is convenient) then the bulk of the compiler need 
'I re-entrant in the true sense, but merely a collection of 
ion subroutines. Each user will have an impure area 
'input/output buffers, his source program and other 
— dent information. The actual translation and control 

- will be scheduled by line quantum on a ‘round robin’ 
>y a ‘sub-monitor’. 

^sub-monitor is run by the monitor as a normal time- 

- fob with a higher degree of communication between 
ibnitor and sub-monitor, particularly with regard to 
--•I output. It is the teletype input and output which 

most difficulties and will require re-entrant pro- 

- to be implemented. 

in reasons for the line scheduling approach is that 
fly-are there fewer monitor modifications but less re- 
programming which takes longer to debug as it is 
I’fficult to reproduce the exact situation dependent on 


two or more people When a failure occurs. The major dis- 
advantage will be lack of compatibility with the DEC re- 
entrant facilities. Dynamic storage of impure areas creates 
additional problems with swapping systems, but by being aware 
of the requirements of full re-entrancy it should not be too 
difficult to modify FORDESK when the current system is 
expanded. 

CONCLUSION 

Six months’ experience with a limited time shared system 
has reaffirmed that such systems are particularly suited to the 
University environment in which program development and 
teaching dominate the daily work load. ' 

Man machine interaction — the main attraction of time shar- 
ing— is enhanced if software has been designed with this com- 
munication in mind. Suitable on-line software for program 
debugging at both the assembly language and algebraic com- 
piler level, possibly the most common form of interaction in 
a time shared system, will raise user efficiency and hence 
further raise machine efficiency. 
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